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Preface 


This  was  the  final  effort  I  made  for  the  Air  Force.  In  the  past  1 2  years,  my  goal 
has  been  to  make  other's  jobs  the  easiest  and  least  stressful  as  possible  through  con¬ 
trolling,  modifying,  or  eliminating  the  bureaucracy  inherent  in  my  work  and  increasing 
the  communication  and  cooperation  between  all  those  I  have  come  in  contact  with.  My 
hope  is  that  this  work  will  continue  that  tradition  with  recommendations  that,  if 
implemented,  would  lead  to  greater  communication  between  people  and  support  systems. 

Just  as  in  all  my  endeavors,  this  is  not  the  effort  of  one  man,  but  a  compilation  of 
the  work  of  many  people.  My  thanks  goes  to  the  Greene  County,  Montgomery  County, 
Wright  State  University,  Air  Force  Institute  of  Technology,  and  the  2750th  Air  Base 
Wing  Master  Publications  librarians  who,  on  multiple  occasions,  spent  time  and  effort 
trying  to  locate  references  that  did  not  exist.  I  tiiank  the  people  at  the  Standard  Systems 
Center,  Gunter  Air  Force  Base,  Alabama,  who  took  the  time  to  explain  to  an  ignorant 
researcher  how  their  systems  worked  and  identified  contact  points  and  information 
gurus  for  the  same.  Without  the  reams  of  documentation,  briefings,  and  historical 
documents  they  sent,  the  background  for  each  of  the  systems  under  study  would  have  been 
impossible  to  construct.  I  also  thank  the  2750th  Logistics  Squadron  and  the  2046th 
Communications  Group  for  allowing  me  to  witness  the  workings  and  learn  some  of  the 
intricacies  of  the  systems. 

I  appreciated  Majors  Wayne  Stone  and  Ste\«  Teal's  balanced  perspective  and  how 
they  ensured  the  quality  and  timeliness  of  the  thesis. 
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Finally,  to  Debbie,  my  wife  of  1 4  years,  I  would  not  have  completed  this  program 
or  thesis  without  her  encouragement  and  suf^^rt-  Thanks  are  too  small  a  compensation. 
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Abstract 


A  change  within  the  Air  Force  has  shifted  management  responsibilities  within  the 
logistics  community.  Formerly  diverse  functions  have  come  under  the  purview  of  a 
single  manager— the  Logistics  Group  Commander— who  has  inherited  information  systems 
that  may  not  be  able  to  provide  consolidated  information  for  informed  and  accurate 
decision  making.  The  purpose  of  this  thesis  was  to  describe  the  current  and  potential 
ability  for  three  logistics  information  management  systems  to  share  data:  Standard  Base 
Supply  System,  Consolidated  Aircraft  Management  System,  and  On-Line  Vehicle 
Information  Management  System. 

A  systems  model  was  synthesized  from  the  literature  review  to  determine  what 
components  of  a  system  may  impact  data  sharing.  Identified  were  input  and  output, 
applications  without  a  database  management  system,  absence  of  a  database  management 
system,  and  the  data  itself. 

Data  was  gathered  through  the  study  of  each  system's  documentation  along  with 
interviews  from  systems  managers  and  experts.  It  was  found  that  documentation  for 
system  data  was  inadequate  and  was  the  largest  obstacle  to  data  sharing. 

Recommendations  included  revising  documentation,  providing  more  input  and 
output  capability  for  the  On-Line  Vehicle  Information  Management  System,  and 
redesigning  the  On-Line  Vehicle  Infonnation  Management  System  to  operate  around  a 
database  management  system. 


AUTOMATED  LOGISTICS  INFORMATION  SYSTEMS: 


A  CASE  STUDY 


I.  The  Problem 


Introduction 

Rapid  and  pervasive  changes  have  occurred  within  the  United  States  economy  and 
the  international  politico-military  situation  leading  to  a  massive  streamlining  of  the  Air 
Force.  Operational  controls  have  been  reoriented.  Functional  areas  have  been  redefined, 
regrouped,  and  reorganized.  Some  structures  have  been  eliminated  and  others  have  been 
changed  so  that  they  bear  little  resemblance  to  their  previous  forms.  Throughout  this 
streamlining,  the  basic  building  block  of  the  Air  Force  has  remained  virtually  intact— 
the  operational  wing.  The  wing  has  not  remained  unscathed,  however. 

Background  of  the  Problem 

Prior  to  1992,  the  predominant  structui^e  of  the  Air  Force  Wing  was  the  tri¬ 
deputy  system.  This  structure  consisted  of  a  deputy  commander  of  operations,  deputy 
commander  of  maintenance,  and  deputy  commander  of  resource  management.  Figure  1  is 
an  organization  structure  chart  for  a  standard  tri-deputy  wing. 

In  early  1992,  General  Merrill  A.  McPeak,  Chief  of  Staff  of  the  Air  Force,  iden¬ 
tified  an  "objective  wing"  in  which  logistics  functions  were  aligned  under  a  Logistics 
Group  Commander  and  most  aircraft  inaintenance  functions  were  aligned  under  flying 
squadron  commanders  (McPeak,  1 992).  Figure  2  is  an  organization  structure  chart  of 
the  objective  wing. 
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Statement  of  the  Problem  Situation 


Logistics  information  systems  were  designed  for  the  tri-deputy  wing  (Figure  1 ) 
with  management  and  operations  responsibility  for  each  system  residing  with  the 
appropriate  functional  manager.  The  objective  wing  structure  brought  nrrost  logistics 
information  systems  under  the  management  control  of  a  single  manager  the  Logistics 
Group  Commander.  This  was  a  major  shift  from  the  fornner  organization  (McPeak, 
1992). 

The  Logistics  Group  Commander,  under  the  objective  wing,  is  responsible  for 
five  diverse  functions— logistics  support,  supply,  aircraft  maintenance  (limited  to  some 
centralized  functions),  transportation,  and  contracting— with  each  function  supported  by 
its  own  automated  information  system.  For  the  Commander  to  acquire  the  data  necessary 
for  informed  decision-making,  each  functional  area  has  to  be  tasked  for  the  relevant 
information.  This  information  then  has  to  be  consolidated  for  consumption. 

An  automated  information  system  able  to  query  all  of  the  individual  systems  and 
then  consolidate  the  data  appropriately  could  result  in  more  efficient  and  accurate 
decision  making  by  the  Logistics  Group  Commander  (Davis,  1 988). 

The  single  largest  obstacle  to  implementing  such  an  automated  information 
system  is  the  limited  ability  to  share  data  between  current  systems.  Data  sharing  means 
that  the  individual  pieces  of  data  can  be  understood  and  used  by  the  different  systems 
(Date,  1 990:7).  For  data  to  be  shared,  it  must  be  defined  identically  by  all  systems.  In 
essence,  implementing  such  a  design  results  in  a  single  database  that  all  systems  can 
access  (Date,  1990:44,  Nguyen,  1991). 

Developing  such  a  database  design  is  the  responsibility  of  the  Secretary  of  the  Air 
Force,  Under  Secretary  for  Acquisition.  This  office  strives  to  provide  the  Air  Force  with 
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one  definition  for  every  piece  of  data  used  in  every  Air  Force  information  system.  In  a 
28  April  1 992  telephone  interview,  Bao  T.  Nguyen,  Air  Force  Data  Manager,  related  that 
developing  a  single  definition  for  a  data  name  has  been  difficult  because  the  information 
culture  of  the  Air  Force  has  been  built  around  independent  information  systems. 
Information  systems  have  grown  up  along  functional  lines  with  little  interaction  outside 
their  respective  functions.  This  trend  has  caused  identical  data  names  to  appear  in 
different  systems  but  with  diverse  definitions. 

In  order  to  standardize  data  definitions,  eliminate  duplication  of  effort,  and  inte¬ 
grate  information  systems  within  the  Air  Force,  information  systems  must  be  designed 
from  their  very  inception  with  data  sharing  as  a  primary  requirement.  Current 
operational  systems  may,  therefore,  require  a  complete  redesign  to  implement  data 
sharing. 

Purpose  of  the  Study 

The  purpose  of  this  thesis  was  to  describe  the  current  and  potential  ability  for 
three  logistics  information  management  systems  to  share  data.  Each  system  was  studied 
to  find  commonalties  that  would  indicate  that  data  sharing  had  or  could  occur. 

Description  of  the  Study 

Systems  for  this  study  were  chosen  from  three  functional  areas  under  the  control 
of  the  Logistics  Group  Commander.  In  order  to  analyze  each  system,  specific  portions 
were  studied  in  detail.  The  purpose,  requirements  definition,  structure,  operating 
environment,  data,  input,  output,  and  interface  abilities  were  studied  to  determine 
similarities  and  differences  between  the  systems.  The  study  was  descriptive  in  nature 
using  a  case  study  approach. 
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Importance  of  the  Study 


This  study  perforrDed  two  functions.  First,  the  study  served  as  a  historical 
perspective  on  logistics  information  systems  within  a  changing  Air  Force. 

Second,  this  study  may  serve  as  a  basis  for  further  research  in  designing  a  fully 
integrated  information  system  within  the  logistics  community.  Additional  investigations 
broadening  the  scope  of  the  current  study  would  serve  to  expand  knowledge  of  current 
system  interactions  and  potentially  result  in  a  stronger  basis  for  replacement  systems. 

Scope  of  the  Study 

Due  to  the  diversity  of  logistics  information  systems,  it  was  not  possible  to 
compare  all  available  systems.  The  systems  chosen  for  this  study  were  implemented  Air 
Force-wide  and  represented  functional  areas  under  the  Logistics  Group  Commander. 
Systems  represent  supply,  transportation,  and  aircraft  maintenance  functional  areas. 

Definition  of  Terms 

Application.  1 .  The  task  to  be  accomplished  by  a  computer  system;  for  instance: 
word  processing,  accounts  payable,  and  statistical  analysis  (Hipgrave,  1 985; 
Pfaffenberger,  1 991 ).  2.  The  integration  of  logically  related  programs  to  accomplish  a 
specific  purpose  (Ahituv  and  Neumann,  1 990;  Senn,  1 989).  Applications  have  been 
used  as  a  user  interface  or  "front  end"  to  database  management  systems  (Date,  1 990). 

Artificial  Intelligence.  A  computer  science  field  that  attempts  to  improve 
computers  endowing  them  with  some  of  the  characteristics  associated  with  human 
intelligence,  such  as  the  capability  to  understand  natural  language  and  to  reason  under 
conditions  of  uncertainty  (Pfaffenberger,  1991). 
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Data.  A  general  term  used  to  denote  the  raw  facts  and  figures  that  are  used  for 
discussion,  decision-making,  calculating,  or  measuring  (Hipgrave,  1985;  McLeod, 

1 986).  Data  is  in  the  form  of  letters,  numbers,  and  symbols  and  can  be  contained  inside 
or  outside  of  an  automated  system.  For  the  purpose  of  this  paper,  data  will  be  considered 
to  be  stored  within  an  automated  system  or  on  magnetic  medium. 

Data  Dictionary.  This  term  is  alternately  referred  to  as  a  data  directory  or 
meta-data  (Hipgrave,  1985;  Date,  1990;  Pfaffenberger,  1991).  Within  a  database 
management  system,  the  data  dictionary  contains  the  explanation  of  the  format  of  the  data 
within  the  database.  It  also  includes  definitions  of  other  objects  in  the  database,  the 
structure  of  the  database,  and  how  different  users  view  the  data.  A  comprehensive  data 
dictionary  may  include  cross  references  on  what  data  is  used  in  which  applications, 
which  users  require  which  reports,  and  what  terminals  are  connected  to  the  system. 

Data  Element.  A  single  unit  of  data  within  a  database  (Hipgrave,  1 985;  Date, 

1 990).  For  instance,  DATE  would  be  a  data  element  within  most  databases. 

Data  Sharing.  Multiple  applications,  users,  and  processes  have  access  to  indi¬ 
vidual  pieces  of  data  and  can  use  that  identical  piece  of  data  for  different  purposes. 
Simultaneous  (concurrent)  access  is  also  implied  (Date,  1 990). 

Database.  A  computerized  collection  of  related  information  about  a  subject 
organized  in  a  useful  manner  that  provides  a  base  or  foundation  for  procedures  such  as 
retrieving  information,  drawing  conclusions,  and  making  decisions  (Date,  1 990; 
Pfaffenberger,  1991).  This  data  repository  is  accessed  by  using  the  computer's 
software  (Hipgrave,  1985;  Date,  1990). 
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Database  Management  System  (DBMS).  A  software  package  that  facilitates  the 
creation  and  manipulation  of  a  database  (Date,  1990;  Hipgrave,  1985;  McLeod,  1986). 
Some  of  the  functions  the  DBMS  performs  include  defining,  processing,  retrieving, 
adding,  changing,  or  deleting  data  within  a  database  (Date,  1990;  Kroenke,  1992; 
Pfaffenberger,  1991). 

Flat  File  Database.  A  database  that  stores,  organizes,  and  retrieves  information 
from  only  one  file  at  a  time  (Pfaffenberger,  1991). 

Hardware.  The  physical  components  of  the  computer.  It  includes  input  devices, 
output  devices,  one  or  more  processing  units,  memory,  and  storage  devices.  The 
hardware  is  incapable  of  manipulating  data  by  itself.  With  instructions  from  a  program, 
the  hardware  is  able  to  move  and  process  data  (Hipgrave,  1 985;  Savitch,  1 988; 

Sullivan,  Lewis,  and  Cook,  1 985). 

Logistics  Information  System.  Managennent  information  systems  that  are 
specifically  designed  for  the  logistics  environment. 

Management  Information  System  (MIS).  An  information  system  that  provides 
managers  at  all  levels  of  an  organization  with  the  information  needed  for  making  deci- 
sions  by  exploiting  the  data  held  within  the  database  (Hipgrave,  1 985;  Ahituv  and 
Neumann,  1992). 

On-Line  Processing.  Processing  mode  where  transactions  are  entered 
immediately  into  the  database  system  (McLeod,  1 986). 

Operating  system.  The  software  that  is  used  as  an  interface  between  the  user,  the 
applications,  the  database  management  system,  and  the  physical  hardware  of  a  computer. 
The  operating  system  supervises  the  workload  of  the  computer,  controls  input  and 
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output,  manages  the  computer’s  memory,  places  data  on  storage  media,  protects  the  user 
from  errors  within  the  computer  or  application,  provides  a  way  to  share  data  between 
programs,  and  controls  the  sequence  of  execution  for  programs  (Hipgrave,  1 985; 

Lister,  1984). 

Schema.  A  complete  logical  view  of  the  database  (Kroenke,  1 992). 

Software.  1 .  A  general  term  for  a  computer  program,  collection  of  programs, 
operations,  or  routines  used  to  carry  out  tasks  on  a  computer.  2.  Anything  that  is  not 
hardware,  including  documentation  (Hipgrave,  1985). 

Transaction.  1.  An  event  that  requires  or  generates  data.  2.  A  change  of  data 
within  a  database.  3.  A  complete  processing  operation  (Hipgrave,  1985). 

Transmission  Control  Procedure/Intemet  Protocol  (TCP/IP).  A  file  transfer 
protocol  for  use  in  electronically  connected  computers.  TCP/IP  was  developed  by  the 
U.S.  Department  of  Defense  (Stamper,  1991). 

Outline  of  the  Remainder  of  the  Thesis 

Chapter  I  introduced  the  thesis  problem  and  detailed  why  it  is  important  to  study 
the  potential  for  interaction  between  current  logistics  information  systems.  It  concluded 
with  definitions  of  terms  used  throughout  the  thesis.  Chapter  II  reviews  the  literature 
on  data  sharing  and  introduces  the  three  logistics  information  systems.  Chapter  III 
describes  the  case  study  method  and  the  particuiar  methodology  of  this  thesis.  Chapter  IV 
provides  a  comparative  analysis  of  each  system.  Finally,  Chapter  V  summarizes  the 
previous  four  chapters,  draws  conclusions  about  the  interaction  of  the  three  logistics 
information  systems  under  study,  provides  recommendations  for  enhancing  data  sharing, 
and  identifies  further  opportunities  for  research. 
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II.  Review  of  Related  Literature 


Organization  of  the  Present  Chapter— Overview 

This  chapter  begins  with  a  history  of  shared  data  technology,  theories  of  data 
sharing,  and  concludes  with  an  introduction  to  the  three  logistics  information  systems 
being  studied. 

History  of  Data  Sharing  Technoloav 

Computers  were  first  used  for  business  applications  in  the  1950s.  Slow, 
cumbersome,  and  highly  inefficient  programs  were  written  in  machine  language,  a  code 
composed  entirely  of  Os  and  Is.  Input  and  output  was  in  the  form  of  punched  cards.  Data 
groups  in  these  computers  were  in  the  form  of  fields,  typically  expressed  in  bits,  bytes, 
and  words.  With  the  low  level  of  these  constructs  and  the  relative  scarcity  of  computers, 
there  was  no  need  for  data  sharing.  Programmers  produced  unique  programs  for  unique 
machines  that  performed  unique  operations  on  unique  data.  (Jones,  1992;  Sullivan, 
Lewis  and  Cook,  1 985) 

Not  until  the  1 960s  with  the  advent  of  the  transistor  and  high-level 
programming  languages,  were  computers  considered  economically  viable  for  general 
business  purposes.  With  the  introduction  of  the  COmrrwn  Business  Oriented  Language 
(COBOL),  programmers  were  able  to  describe  data  in  more  general  terms.  COBOL 
provided  the  concept  of  fields  linked  together  to  form  records,  and  records  linked 
together  to  form  files.  Two  major  limitations  plagued  the  early  systems,  however. 

First,  records  could  only  be  accessed  within  files  in  two  ways:  sequentially  or  directly. 
Sequential  access  means  that  to  locate  an  individual  record,  every  record  in  a  file  had  to 
be  read,  starting  at  the  beginning  of  the  file,  until  the  record  needed  was  found.  Direct 
access  means  that  the  exact  location  of  the  record  within  the  file  had  to  be  known  to 
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access  it.  Accessing  data  was  a  problem  because  the  location  of  the  specific  record  was 
contained  only  within  the  application.  Data  used  within  one  application  was  worthless  to 
another  because  of  inconsistencies  in  the  way  each  application  stored  data.  Access  limi¬ 
tations  were  overcome  in  the  late  1 960s  with  the  introduction  of  access  methods  within 
software  utilities  called  file  management  systems.  'These  systems  developed  and  stan¬ 
dardized  models  for  organizing  files  and  methods  for  accessing  records  within  files" 
(Jones,  1 992:  58).  Data  storage  methods  were  no  longer  application  specific. 

The  second  limitation  with  early  systems  was  that  files  were  formatted  and  owned 
in  a  proprietary  fashion  by  the  using  application.  Data,  records,  or  files  from  one 
application  could  not  be  shared  with  other  applications.  This  limitation  was  not 
overcome  until  1 971  when  the  Corronittee  On  DAta  SYstems  Languages  (CODASYL) 
standardized  the  network  data  model  as  the  database  organization  structure.  The  network 
model  allowed  a  host  language  (such  as  COBOL)  to  manipulate  data  through  a  "call" 
sequence  that  insulated  the  programmer  from  the  data,  allowing  multiple  applications  to 
access  the  same  data  (Date,  1990).  The  network  data  model  provided  a  good  foundation 
for  data  sharing,  but  was  not  understood  by  users.  "The  users  could  not  effectively 
communicate  their  requirements,  understand  the  constraints  imposed  on  them  by  these 
systems,  or  control  their  own  data  management  destiny"  (Jones,  1992:  58). 

In  1 970  and  1 971 ,  E.  F.  Codd  defined  a  mathematically  based  data  organization 
approach  that  was  specifically  designed  to  provide  for  the  integration  of  databases  and  the 
development  of  integrated  database  systems.  The  data  was  stored  in  tables  with  no 
physical  linkage  between  the  tables.  Data  manipulation  was  provided  through  a  language 
that,  like  the  network  model,  could  be  called  from  a  host  language.  The  language  could 
also  be  used  independently  to  provide  ad  hoc  inquiries  in  near  English.  This  "relational" 
database  enabled  users  and  developers  to  overcome  the  shortcomings  of  the  network 
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model.  It  was  not  until  the  1 980s  that  developers  of  the  relational  database  management 
systems  (RDBMS)  began  to  standardize  their  data  manipulation  language.  Systems  Query 
Language  was  standardized  by  the  American  National  Standards  Institute  and  the  Inter¬ 
national  Organization  for  Standardization  allowing  for  an  almost  universal  acceptance  of 
the  language  (Jones,  1 992;  Date,  1 990). 

Theories  of  Data  Sharing 

Data,  in  complex  organizations,  usually  reside  in  many  different  forms  and  in 
many  locations.  Problems  become  apparent  when  trying  to  access,  validate,  and  share 
the  data.  Older  systems  may  be  in  application-unique  formats  while  newer  systems  may 
store  data  within  a  standardized  format.  Even  though  standards  exist  in  nrxxiem  systems, 
there  is  enough  leniency  within  the  standards  so  that  products  from  different  suppliers 
do  not  always  work  with  the  data  stored  by  a  competitor's  product  Some  database 
management  systems  are  not  flexible  enough  to  cross  the  boundaries  between 
microcomputers,  minicomputers,  and  mainframe  computers.  In  order  to  overcome  data 
obstacles,  the  user  needs  to  access  all  of  the  data  regardless  of  where  or  in  what  form  it 
resides  (Brown,  1991;  Jones,  1992;  Rasmus,  1991).  Differences  arise,  though,  in 
exactly  how  data  sharing  should  be  accomplished. 

This  survey  of  recent  literature  revealed  that  there  are  at  least  two  poles  of 
thought  on  sharing  data.  All  of  the  literature  acknowledged  that  fully  shared  data,  in  any 
form,  was  not  available  at  the  time  of  this  writing. 

The  majority  of  the  literature  reflected  the  opinion  that  the  best  way  to  assure 
data  sharing  was  to  design  systems  with  sharing  in  mind  ((Soodhue  and  others,  1 992; 
Jones,  1992;  Staples  and  Sharon,  1992;  Von  Halle,  1992,  Wolf  and  others,  1989).  One 
advocated  the  use  of  a  centralized  data  repository  that  would  provide  users  with  identical 
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access  to  all  data  regardless  of  where  the  data  may  be  physically  stored  or  the  type  of 
data  management  system  used  (Jones,  1 992).  Another  advocated  designing  all  systems 
around  a  comnnon  information  systems  data  model  to  facilitate  the  sharing  of  data  (Von 
Halle,  1992).  Not  all  reports  were  optimistic  concerning  the  implementation  of  shared 
data,  however.  Although  planning  and  implementing  data-integrated  systems  appeared  to 
be  the  answer  for  sharing  problems,  in  reality,  few  organizations  have  succeeded.  The 
primary  reason  for  failure  was  that  firms  were  not  prepared  to  undertake  the  cost  of 
rewriting  all  systems  necessary  to  support  the  complete  sharing  of  data  ((kxxJhue  and 
others,  1992). 

A  contrasting  opinion  was  that  re-engineering  all  systems  was  not  necessary  to 
provide  access  to  all  data.  An  open  system  interface  that  allowed  all  users  to  access  data 
residing  in  any  machine  or  management  system  would  provide  the  same  function  as 
making  the  environment  homogeneous.  The  basic  premise  was  that  an  artificial  intel¬ 
ligence  rrwdule  would  be  used  to  identify  the  requestor  and  where  the  information 
resided.  The  module  would  interpret  the  request  and  compile  Information  from  a  variety 
of  databases  on  several  hardware  platforms.  It  would  then  return  the  results  in  a  format 
useable  by  the  requestor  (Rasmus,  1991). 

There  was  a  wide  range  of  opinion  as  to  who  or  what  was  to  blame  for  the 
inability  of  data  to  be  shared.  Parallel  development  of  software  systems  without  coor¬ 
dination  or  sharing  of  technologies  was  one  reason  identified  for  the  difficulty  in  estab¬ 
lishing  interfaces  between  systems  or  in  developing  an  integrated  approach  to  the  entire 
system  design  problem  (Davis,  D.,  1987).  The  data  owners'  refusal  to  share  was 
mentioned  as  an  additional  contributing  factor  (Van  Halle,  1992).  The  inability  for 
current  standards  to  deal  with  in-place  systems  might  have  also  been  an  element  of  the 
problem  (Jones,  1 992).  Another  reason  offered  was  that  the  standards  were  available, 
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but  were  not  enforced  (Brown,  1991).  All  agreed  that  a  concerted,  coordinated  effort 
was  necessary  to  produce  an  integrated  data  environment. 

*  Conclusions 

In  spite  of  the  wide  variety  of  perceived  causes  for  the  lack  of  data  sharing,  only 
two  solutions  were  suggested  in  literature.  The  majority  of  the  contributors  advocated 
redesigning  all  applications  around  a  common  framework  to  solve  the  sharing  problem. 
An  alternative  suggested  by  one  source  was  to  develop  an  open-system  interface  with  the 
capability  to  act  as  a  translator  between  dissimilar  systems. 

Introduction  to  Logistics  Information  Systems 

Standard  Base  SuddIv  System  (SBSS).  In  1 963,  the  Air  Force  formed  the 
Supply  Systems  Design  Office  to  "develop  and  control  a  standard  USAF  base  supply 
electronic  data  processing  system"  (Special  Order  G-58,  21  June  1963).  One  of  the 
first  automation  efforts  in  the  Air  Force,  the  SBSS  functioned  as  a  stand-alone  system. 
Interaction  with  other  systems  was  through  punched-card  transactions.  Transactions 
from  the  SBSS  for  supply  issues  (office  supplies,  equipment  issues,  fuel,  and  so  on) 
were  output  on  card  decks  which  were  then  carried  to  the  punched-card  reader  of  other 
systems  for  processing.  Verification  was  through  manual  comparison  of  printed  output 
from  both  systems  (Tyson,  1 992). 

By  1 983,  modifications  to  the  SBSS  allowed  data  to  be  transferred  electronically 
to  the  accounting  and  finance  system.  Updates  from  the  SBSS  were  consolidated  and 
processed  once  a  week  with  automated  verification.  Later  SBSS  revisions  allowed  for 

# 

more  frequent  updates,  but  still  only  in  consolidated  groups  and  not  immediately.  With 

*  Increment  II  of  the  consolidated  aircraft  management  system  (CAMS),  a  maintenance- 

supply  interface  was  formed  which  allowed  parts  ordering  and  status  updates  to  be 
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performed  through  the  CAMS  in  individual  transactions  without  lengthy  delays  (Tyson, 
1992;  FD-G83-004  Basic,  1983). 

Consolidated  Aircraft  Management  System  (CAMS).  The  newest  of  the 
systems  studied,  CAMS  was  initiated  5  May  1 983  when  HQ  USAF  Data  Project  Directive 
DPD-HAF-G83-004  was  issued.  CAMS  was  to  replace  the  Maintenance  Management 
Information  and  Control  System  used  to  gather  maintenance  data,  man-hour  usage,  and  to 
track  personnel  training  and  certification  (Hill,  1992).  ImplerDented  in  seven 
increments,  CAMS  was  to  have  all  the  capabilities  of  its  immediate  predecessor  as  well 
as  (1 )  on-line  maintenance  data  collection  and  work  order  generation,  (2)  a 
maintenance-supply  interface,  (3)  automated  debriefing  and  Air  Force  Technical  Order 
Form  781 -series  forms  generation,  (4)  administrative/logistics  and  personnel 
availability  tracking,  (5)  automated  scheduling  and  multiple  status  inventory  reporting 
system,  (6)  follow-on  comprehensive  engine  management  system,  and  (7)  quality  con¬ 
trol/assurance  and  production  scheduling  (FD-G83-004  Basic,  1 983). 

On-Line  Vehicle  Interactive  Management  System  (OLVIMS).  From  1971, 
vehicle  maintenance  control  relied  upon  the  Vehicle  Integrated  Management  System 
(VIMS),  a  mainframe,  punched-card  system,  for  data  management.  In  the  late  1 970s, 
the  Air  Force  started  a  project  to  upgrade  VIMS  to  run  on  the  replacement  to  the 
Burroughs  base  computer,  the  Sperry  1 1 00.  This  system  would  allow  operators  to 
update  records  and  produce  reports  immediately  from  terminals  rather  than  having  to 
produce  punched  cards  and  wait  days  for  printed  reports.  However,  the  project  was 
canceled  in  1985  due  to  a  funds  shortage  (Fry,  1992). 

In  late  1 985,  the  Standard  Systems  Center  began  work  to  move  VIMS  from  the 
mainframe  system  to  the  USAF  standard  microcomputer— the  Zenith  Z-248.  Working  in 
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stages,  the  plan  was  to  initially  provide  Zenith  Z-248s  to  act  as  terminals  for  input  to 
the  VIMS  running  on  the  mainframe  and  then  move  the  processing  from  the  mainframe 
entirely  to  the  Z-248s.  This  first  Air  Force  effort  to  transfer  a  major  system  from  a 
mainframe  to  microcomputers  gave  birth  to  the  On-Line  Vehicle  Interactive  Management 
System  (OLVIMS). 

In  1 986,  OLVIMS  Increment  I  fielded  two  million  dollars  worth  of 
microcomputers  as  data  entry  terminals  and  gave  units  a  key-punch  replacement 
program  with  data  review  and  edit  capabilities.  This  effort  released  the  maintenance 
control  specialists  from  working  only  from  printed  listings  and  punched  cards. 

In  1 988,  Increment  II  of  the  OLVIMS  changed  the  hardware  platform  from  the 
standard  base  computer  to  the  Air  Force  standard  microcomputer.  This  change 
eliminated  the  vehicle  maintenance  facilities'  dependence  on  the  central  data  processing 
center  while  still  maintaining  ail  the  functionality  and  processes  of  the  VIMS.  The  VIMS 
was  decommissioned  in  December  1 988,  after  OLVIMS  was  fully  fielded. 

OLVIMS  III,  fielded  in  May  1 990,  provided  additional  improvements.  It 
automated  work  order  generation,  work  load  control,  warranty  management,  and 
scheduled  maintenance  processing.  This  increment  was  reported  as  saving  over  two 
million  dollars  by  eliminating  excess  forms  and  reports,  increasing  productivity,  and 
enforcing  warranties.  Updates  to  OLVIMS  III  have  added  graphic  analysis  reporting, 
parts  failure  analysis,  and  reporting  aids  for  contracted  operations. 
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Summary  of  the  Literature  Review 


This  chapter  provided  a  history  of  the  development  of  shared  data  technology  and 
progressed  with  theories  of  systems  sharing  and  concluded  with  introductions  to  the 
three  logistics  information  systems  under  study.  Chapter  III  describes  the  case  study 
method  and  the  particular  roethodology  of  this  thesis.  Chapter  IV  provides  a  comparative 
analysis  of  each  system.  Finally,  Chapter  V  summarizes  the  previous  four  chapters, 
draws  conclusions  about  the  interaction  of  the  three  logistics  information  systems  under 
study,  and  identifies  further  opportunities  for  research. 
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III. 


Organization  of  the  Present  Chapter— Overview 

Chapter  III  describes  the  case  study  method  and  explains  why  this  method  was 
chosen  for  use  in  this  study.  This  chapter  also  describes  some  of  the  limitations  of  the 
case  study  method.  This  chapter  concludes  with  a  description  of  the  data  collection 
methods  and  how  the  data  was  chosen. 

The  Case  Study 

A  case  study  "examines  a  phenomenon  in  its  natural  setting,  employing  multiple 
methods  of  data  collection  to  gather  infomiation  from  one  or  a  few  entities  (people, 
groups,  or  organizations).  The  boundaries  of  the  phenomenon  are  not  clearly  evident  at 
the  outset  of  the  research  and  no  experimental  control  or  manipulation  is  used" 

(Benbasat  and  others,  1 987;  370).  The  purpose  for  the  case  study  method  is  to  "see  new 
theoretical  relationships  and  question  old  ones"  (Dyer  and  Wilkins,  1991:614).  The 
case  study  has  established  its  usefulness  in  instruction  and  learning  environments.  It  is 
effectively  used  in  industry  to  analyze  in-house  situations  and  to  direct  problem  solving 
because  of  its  emphasis  on  detail  (B(Jcker,  1987:64;  Emory  and  Cooper,  1991:143; 
Kellogg,  1985:60). 

Why  the  Case  Study 

Selecting  the  case  study  method  over  other  research  methods  was  based  on  three 
conditions:  "(1 )  the  type  of  research  question  posed,  (2)  the  extent  of  control  an 
investigator  has  over  actual  behavioral  events,  and  (3)  the  degree  of  focus  on 
contemporary  as  opposed  to  historical  events"  (Yin,  1989:16).  Using  this  framework, 
each  condition  is  discussed  below  in  relation  to  its  applicability  to  this  thesis. 
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Type  of  Research  Question.  As  described  in  Chapter  I,  the  purpose  of  this  thesis 
was  to  describe  the  current  and  potential  ability  for  three  logistics  information 
management  systems  to  share  data.  Each  system  was  studied  to  find  commonalities  that 
would  indicate  that  data  sharing  had  or  could  occur.  A  restatement  of  the  purpose  in  the 
form  of  a  research  question  would  be;  How  could  the  three  information  systems  share 
data?  The  strategies  applicable  in  answering  a  "how"  question,  as  identified  in  Table  1 , 
are  experiment,  history,  and  case  study  as  opposed  to  survey  and  archival  analysis 
methods  which  delve  into  "how  many"  and  "how  much".  The  second  criteria  for 
determining  a  research  method  is  the  amount  of  control  the  researcher  has  over  the 
subjects. 


TABLE  1 

Relevant  Situations 
for  Different  Research  Strategies 


Strategy 

Form  of  Research 
Question 

Requires  Control  over 
Behavioral  events? 

Focuses  on 
Contemporary 
Events? 

Experiment 

how,  why 

yes 

yes 

Survey 

who,  what,* 
where,  how 
many,  how  much 

no 

yes 

Archival  analysis 
(e.g.,  economic 
study) 

who,  what,* 
where,  how 
many,  how  much 

no 

yes/no 

History 

how,  why 

no 

no 

Case  Study 

how,  why 

no 

yes 

*  "What"  questions,  when  asked  as  part  of  an  exploratory  study,  pertain  to  all  five 
strategies. 


(Yin,  1989:17) 


Extent  of  Control.  The  subjects  of  this  study  are  information  systems  that  are 
managed  centrally  through  the  Air  Force  Standard  Systems  Center.  The  "subjects"  are 
located  at  most  Air  Force  installations  and  are  dynamically  changing  through  system 
maintenance  and  modification  procedures.  In  essence,  no  control  over  behavioral  events 
was  available  for  the  purposes  of  this  research.  Looking  again  at  Table  1 ,  Experiment  is 
eliminated  from  the  strategies  available  because  this  method  requires  control  over 
behavioral  events. 

Focus.  Although  a  limited  historical  perspective  was  given  for  each  logistics 
information  system,  the  major  emphasis  of  the  study  was  on  the  current  systems.  This 
final  criteria  eliminates  all  strategies  except  Case  Study. 

Limitations  of  the  Case  Study  Method 

The  case  study  method  has  several  inherent  limitations.  First,  the  case  study 
method  is  descriptive  rather  than  causal.  The  case  study  can  only  describe  what  events 
have  occurred  without  making  any  inferences  as  to  why  the  events  occurred.  Without  the 
benefit  of  control  over  the  subjects  or  variables,  there  is  no  predictive  ability  within 
the  case  study  method.  No  assumptions  can  be  made  that  identical  circumstances  would 
produce  similar  situations.  The  corollary  to  this  observation  is  that  the  study  can  not  be 
replicated  to  verify  the  results  as  can  be  done  with  experimental  methods. 

Second,  the  case  study  is  designed  for  depth  rather  than  breadth.  Generalizations 
are  not  possible  since  no  attempt  is  made  to  adequately  describe  characteristics  of  a 
population  by  taking  observations  from  a  sample  of  items.  Case  studies  emphasize 
analysis  of  a  limited  number  of  events  and  their  interrelations  within  a  specific  context. 


Third,  although  the  case  study  often  uses  hypotheses,  the  reliance  on  qualitative 
rather  than  quantitative  data  makes  their  support  or  rejection  more  difficult.  The  case 
study  method's  emphasis  on  detail  can  provide  insight  for  problem  solving,  evaluation, 
and  strategy,  however. 

Finally,  as  with  all  research  methods,  the  case  study  relies  on  the  investigative 
prowess  of  the  researcher,  even  more  so  than  with  statistical  and  experimental  methods 
since  the  case  study  can  not  be  replicated.  (Benbasat,  1 987;  Emory  and  Cooper,  1 991 ). 

Data  Collection 

The  primary  data  collection  method  was  through  documentation  research. 

Various  forms  of  documentation  including  Air  Force  regulations,  functional  descriptions, 
and  training  materials  were  reviewed  along  with  briefings  and  other  presentations  on 
the  individual  systems.  Semi-structured  interviews  were  also  used  to  supplement  the 
documentation.  Open-ended  questions  solicited  information  on  background,  application 
output,  and  perceptions  of  usability. 

Data  Evaluation 

A  model  was  needed  to  identify  components  of  information  systems  in  order  to 
determine  what  portions  might  influence  data  sharing  between  systems.  The  first  model 
discovered  was  a  general  systems  model  (Ahituv  and  Neumann,  1 990;  McLeod,  1 986). 
Figure  3  shows  a  representation  of  the  model  used. 


Figure  3.  General  Information  System  Model  (Ahituv  and  Neumann,  1 990; 

McLeod,  1986) 
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This  model  did  not  provide  sufficient  detail,  however.  Senn  suggests  that 
processes  could  be  expanded  to  include  applications,  database  management  systems,  and 
operating  systems  (Senn,  1 989). 


Figure  4.  Expanded  Information  System  Model  (Ahituv  and  Neumann,  1 990; 

McLeod,  1986;  Senn,  1989) 


Applications,  database  management  systems,  and  operating  systems  are  written 
in  programming  languages.  Each  may  be  in  one  or  more  languages;  therefore,  the 
various  languages  could  be  considered  a  component  of  the  information  system  (Sullivan, 
Lewis  and  Cook,  1985). 

The  final  component  of  the  information  system  is  the  physical  portion.  The 
computer  machinery  itself,  the  internal  and  external  accessories,  and  anything  attached 
to  the  machinery,  such  as  communication  lines,  constitute  the  physical  comporrent.  The 
physical  component  is  usually  called  hardware  (Ahituv  and  Neumann,  1 990;  Stamper, 
1991;  Sullivan,  Lewis  and  Cook,  1985).  Figure  5  illustrates  the  complete  information 
system  model.  Notice  that  all  other  components  except  language  are  included  within 
Hardware  since  each  depends,  to  a  greater  or  lesser  extent,  on  the  physical  components 
for  their  usefulness.  Language  includes  the  software  portion  of  the  system. 
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Figure  5.  Complete  Information  System  Model  (Ahituv  and  Neumann,  1990; 

McLeod,  1 986;  Senn,  1 989; 
Sullivan,  Lewis  and  Cook, 
1985) 


Each  of  the  eight  system  components,  (1)  input,  (2)  output,  (3)  applications, 
(4)  database  management  system,  (5)  operating  system,  (6)  language,  (7)  hardware, 
and  (8)  data,  were  scrutinized  to  see  if  any  could  impact  data  sharing.  Below  is  a 
narrative  description  of  each  of  the  components  along  with  a  discussion  of  whether  the 
component  should  or  should  not  be  included  in  the  evaluation  of  the  three  logistics 
support  systems.  Determination  of  inclusion  or  exclusion  was  made  with  the  assistance 
of  thesis  advisors. 


Input  and  Output.  Input  and  output  were  treated  as  one  component  because  inputs 
to  one  system  may  be  outputs  from  another  system  and  similar  or  identical  methods  are 
used  for  both  operations.  An  input  uses  a  mechanical,  electrical  or  magnetic  medium  to 
place  data  within  the  system  in  a  form  that  the  system  can  understand.  Common  input 
methods  include  reading  magnetic  tapes,  magnetic  disks,  and  punched  cards;  typing  on 
terminal  keyboards;  and  using  optical  scanners  and  communications  ports.  Output 
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divulges  the  contents  of  the  system  in  either  a  human  or  machine  readable  format. 
Examples  of  output  methods  included  writing  magnetic  tapes,  disks,  arxl  punched  cards; 
and  sending  data  to  terminal  screens,  printers,  and  communications  ports. 

Without  the  ability  to  physically  transfer  the  data  from  one  system  to  another  on 
a  common  medium,  data  sharing  will  be  extremely  difficult.  The  exact  medium  of 
transfer— electronic  or  mechanical— may  also  have  some  significance  depending  on  the 
time  and  effort  required  to  enact  a  data  transfer.  For  example,  keying  data  into  a 
terminal  from  a  printed  output  may  cost  more  in  time  than  the  value  of  the  data.  Sharing 
data,  although  possible,  may  be  so  time  consuming  and  labor  intensive  that  it  would  not 
be  feasible  except  on  an  infrequent  basis. 

Conclusion:  input  and  output  devices  could  impact  data  sharing. 

Applications.  An  application  is  what  the  vast  majority  of  information  systems 
users  see  and  interact  with.  The  application  Is  an  integration  of  logically  related 
programs  to  accomplish  a  specific  purpose  (Ahituv  and  Neumann,  1 990;  Senn,  1 989). 
Applications  are  used  as  a  user  interface  or  front  end  to  database  management  systems 
(Date,  1990).  Figure  6  shows  the  relationships  between  applications,  database 
management  systems,  operating  systems,  and  hardware. 


I _ End  User _ | 

I  Applications  I — 

I  Database  Manajaement  System  \ 

I  Operating  System  I — 

I  Computer  Hardware  I 

Figure  6.  System  Internal  Relationships  (Date,  1990;  Kroenke,  1992) 
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Conclusion:  based  on  this  design,  applications  used  in  conjunction  with  a  database 
management  system  would  not  significantly  impact  data  sharing.  Applicators  that 
directly  stored,  retrieved,  and  processed  data  without  an  intervening  database  could  have 
a  significant  impact  on  data  sharing. 

Database  Management  System.  A  database  management  system  (DBMS)  is  a 
software  package  that  facilitates  the  creation  and  manipulation  of  a  database  (Date, 

1990;  Hipgrave,  1985;  McLeod,  1986).  Some  of  the  functions  the  DBMS  performs 
include  defining,  processing,  retrieving,  adding,  changing,  or  deleting  data  within  a 
database  (Date,  1990;  Kroenke,  1992;  Pfaffenberger,  1991). 

The  DBMS  controls  the  structure  of  the  data,  that  is,  how  long  it  is,  whether 
numbers,  characters  or  both  were  allowed  and  in  what  order.  It  also  determines  how  the 
data  is  stored  and  retrieved.  The  physical  storage  of  the  data  is  accomplished  through  the 
operating  system.  The  database  management  system  also  passes  data  to  applications  for 
processing. 

Conclusion;  the  database  management  system  could  impact  data  sharing. 

Operating  System.  An  operating  system  is  software  that  is  used  as  an  interface 
between  the  user,  the  applications,  the  datat^e  management  system,  and  the  physical 
hardware  of  a  computer.  The  operating  system  supervises  the  workload  of  the  c»mputer, 
controls  input  and  output,  manages  the  computer's  memory,  places  data  on  storage 
media,  protects  the  user  from  errors  within  the  computer  or  application,  provides  a 
way  to  share  data  between  programs,  and  controls  the  sequence  of  execution  for 
programs  (Hipgrave,  1985;  Lister,  1984). 
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Commercial  products  exist  that  can  move  data  between  operating  systems 
irrespective  of  the  transfer  medium.  Degradation  of  the  data  is  not  a  problem  since  the 
operating  system  does  not  process  or  modify  ^  data. 

Conclusion:  operating  systems  would  not  significantly  impact  data  sharing. 

Language.  A  computer  programming  language  is  a  code  that  gives  the  computer 
instructions  on  how  to  rrtanipulate  data.  The  more  sophisticated  (or  higher)  the 
language,  the  more  closely  the  code  reserr^jles  a  spoken  language.  The  lowest  language, 
machine  code,  is  a  series  of  Os  and  1  s  (Savitch,  1 988). 

Computer  languages  have  the  ability  to  initiate  other  programs  that  are  not 
necessarily  in  the  same  language.  Also,  application  programs  for  a  single  database 
management  system  are  written  in  various  languages  without  affecting  the  ability  of  the 
DBMS  to  perform  its  functions. 

Conclusion:  computer  programming  languages  would  not  significantly  impact  data 
sharing. 

Hardware.  Computer  hardware  is  the  physical  component  of  the  computer.  It 
includes  input  devices,  output  devices,  one  or  more  processing  units,  memory,  and 
storage  devices.  The  hardware  is  incapable  of  manipulating  data  by  itself.  With 
instructions  from  a  program,  the  hardware  is  able  to  nfK>ve  and  process  data  (Savitch, 
1988;  Sullivan,  Lewis,  and  Cook,  1985). 

The  Air  Force,  through  its  contracting  practices,  has  forced  standardization  of 
computer  hardware.  Allowing  buys  only  from  the  standard  small  computer  and  standard 
multi-user  small  computer  contracts  has  resulted  in  almost  homogeneous  computer 
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hardware.  As  older,  non-standard  machines  wear  out  and  are  replaced,  only  standard 
machines  will  remain.  Large  computers  fail  under  similar  criteria. 

Conclusion:  computer  hardware  would  not  significantly  impact  data  sharing. 

Data.  Data  are  the  raw  facts  and  figures  that  are  used  for  discussion,  decision 
making,  calculating,  or  measuring  (McLeod,  1 986).  Data  are  contained  inside,  or 
outside  of  an  automated  system.  For  the  purpose  of  this  paper,  data  are  considered  to  tse 
residing  within  an  automated  system. 

The  data  elements  and  their  corresponding  definitions  are  a  prime  indicator  of  the  ability 
to  consistently  share  data.  Individual  data  elements  with  the  same  name  and  different 
purposes  or  the  same  purpose  but  different  formats  complicate  the  ability  to  share  data. 
On  the  former,  confusion  exists  as  to  whether  a  specific  data  element  is  correct  to  use 
for  accurate  transactions.  The  latter  requires  some  translation  or  may  preclude  sharing 
if  the  format  is  too  limiting. 

Conclusion:  data  could  significantly  impact  data  sharing. 

Conclusion.  After  discussing  the  eight  components  of  an  information  system,  it  is 
found  that,  because  of  their  similarities,  two  can  be  readily  combined  to  form  one.  Of  the 
other  six,  only  half  could  impact  ckita  sharing.  The  final  four  components  that  could 
impact  data  sharing  and  will  be  used  to  evaluate  each  logistics  information  system  are: 

(1 )  input  and  output,  (2)  applications,  (3)  database  management  system,  and  (4)  data. 
Table  2  graphically  depicts  this  summation. 
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TABLE  2 


information  System  Components  and  Data  Sharing 


Component 

Affect  on  Data  Sharing 

1 

Input 

Impact  Combined  with  2 

2 

Output 

Impact  Confined  with  1 

3 

Applications 

Significant  Impact  if  no  DBMS 

■■ 

Database  Management  System 

Impact 

5 

No  Impact 

6 

Language 

No  Impact 

7 

Physical 

No  Impact 

8 

Data 

Significant  Impact 

Summary 

Chapter  III  described  the  case  study  method,  explained  why  it  was  chosen  for  use 
in  this  study,  and  described  some  limitations  of  the  case  study  method..  This  chapter  also 
discussed  what  data  collection  methods  were  used  and  how  the  data  were  evaluated. 
Chapter  IV  describes  the  the  four  factors  considered  significant  to  data  sharing  within 
Chapter  III:  input  and  output  devices,  applications,  database  management  system,  and 
data,  in  relation  to  the  three  logistics  information  systems.  Finally,  Chapter  V 
summarizes  the  previous  four  chapters,  draws  conclusions  about  the  interaction  of  the 
three  logistics  information  systems  under  study,  and  identifies  further  opportunities  for 
research. 
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IV.  Findings 

Organization  of  the  Present  Chapter— Overview 

Chapter  IV  describes  the  the  four  factors  considered  significant  to  data  sharing 
within  Chapter  III:  input  and  output  devices,  applications,  database  management  system, 
and  data,  in  relation  to  the  three  logistics  information  systems. 

Findings 

Findings  for  input  and  output,  applications,  and  database  management  system  are 
summarized  in  Table  4,  below.  Explanations  follow  the  table. 


TABLE  3 

Comparison  of  Logistics  Information  Systems  and  System  Components 


Component 

CAMS 

SBSS 

OLVIMS 

Input  and  Output 

Sperry  1100/ 
2200  Based 

Sperry  1100/ 
2200  Based 

Microprocessor 

Based 

ICI 

ICI 

1  /2  inch  Mag 
Tape 

1/2  inch  Mag 
Tape 

1  /4  inch  Mag 
Tape 

5  1/4  inch 
Floppy  Disk 

5  1/4  inch 

Floppy  Disk 

Terminals 

Terminals 

Terminal 

DON 

DON 

Printers 

Printers 

Printers 
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TABLE  3,  Continued 


Component 

CAMS 

SBSS 

OLVIMS 

Applications 

Front  end  to 
DBMS 

Front  end  to 
DBMS 

Direct  Data 
Manipulation 

Database 

Management 

System 

Network 

Hierarchical 

None 

(AFM  66-279,  Vol  XXVII,  1992;  AFM  67-1,  Vol  II,  Part  4,  Chapter  5,  Section 
A,  1991;  AFM  77-320  Vol  I,  1992;  Tyson,  1992;  Steinhardt,  1992) 


Input  and  Output.  The  SBSS  and  CAMS  reside  on  the  same  Sperry  1 1 00  or  2200 
series  mainframe  computer,  depending  on  what  is  installed  at  the  particular  location. 
Sharing  hardware  greatly  facilitates  their  sharing  data.  The  Interactive  Communication 
Interface  (ICI),  an  operating  system  utility  program,  aids  in  transferring  data  between 
the  SBSS,  CAMS  and  other  systems.  It  allows  formatted  data  to  be  transferred  from  one 
system  to  another  or  between  different  locations.  Between  two  locations,  the  ICI  will 
format  the  data  for  transfer  over  the  Defense  Data  Network  (DDN)  using  a  transmission 
control  procedure/internet  protocol.  (AFM  66-279,  Vol  XXVII,  1992;  AFM  67-1,  Vol 
II,  Part  4,  Chapter  5,  Section  A,  1991;  Tyson,  1992;  Steinhardt,  1992). 

The  OLVIMS  resides  on  the  standard  Air  Force  Microcomputer.  Input  and  output 
are  somewhat  limited  because  there  is  no  provision  for  data  transfer  by  way  of 
communications  lines,  either  DDN  or  telephone.  Limited  data  transfer  between  OLVIMS 
and  SBSS  is  carried  out  by  placing  data  on  a  5  1  /4  inch  magnetic  floppy  disk  and 
physically  carrying  it  to  the  other  system.  Updates  and  reports  that  are  required  by 
higher  headquarters  are  transferred  by  means  of  a  magnetic  disk  through  the  mail. 
Other  than  printing  data  from  one  system  and  then  keying  the  data  through  a  terminal  on 
the  other  system,  there  are  no  common  transfer  mediums  between  OLVIMS  and  CAMS 
(AFM  77-320  Vol  I,  1992;  Guchian,  1992;  Steinhardt,  1992;  Teti,  1992). 
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Applications.  The  SBSS  and  CAMS  applications  function  as  a  front  end  to  the 
database  management  systems  for  their  respective  systems.  The  applications  do  not  deal 
with  the  data  directly:  therefore,  the  applications  neither  help  nor  hinder  data  sharing. 

The  OLVIMS  is  a  data  storage  and  retrieval  application  without  a  database  system. 
Applications  manipulate  the  data  directly  instead  of  going  through  a  file  management  or 
data  management  system.  Two-way  links  between  files  are  identified  within  the  files 
themselves,  but  the  location  of  the  links  within  the  file  is  only  known  by  the  application. 
Application  dependence  makes  data  sharing  difficult,  but  not  impossible.  In  order  to 
share  data  with  other  than  OLVIMS  applications,  an  application  must  be  used  that  knows 
exactly  where  the  data  and  its  corresponding  links  are.  In  addition,  access  to  data  within 
the  files  is  through  keys  and  subkeys.  In  order  to  recall  specific  data,  an  operator  has  to 
know  the  specific  key,  usually  a  vehicle  number  or  a  work-order  number  (Farrell, 
1992). 


Database  Management  System.  Both  the  SBSS  and  the  CAMS  use  a  database 
management  system.  Application  independence  allows  data  to  be  shared  more  easily  since 
data  can  be  manipulated  without  having  intimate  knowledge  of  the  way  the  data  is 
physically  stored  within  the  system. 

The  SBSS  database  uses  the  Sperry  Data  Management  System— 1100  for  data  base 
definition.  The  SBSS  database  is  designed  using  the  CODASYL  Worldwide  Standards 
Committee  specifications.  Access  to  the  database  is  through  a  hierarchical  relationship. 
In  order  to  navigate  through  the  database,  several  levels  have  to  be  traversed,  '^irst,  the 
area  is  located,  then  the  record  within  the  area,  and,  finally,  the  data  element  within  the 
record.  The  database  is  divided  into  38  areas,  and  244  records.  Records  are  further 
grouped  into  nine  types  or  categories  to  aid  in  reports  and  reports  processing.  Record 


30 


types  are  scattered  throughout  the  areas  and  were  not  limited  to  one  type  in  any  one  area 
(AFM  67-1,  Vol  II,  Part  4,  Chapter  5,  Section  A,  1991). 

The  description  of  the  database  (including  how  the  data  is  stored)  is  contained 
within  the  database  itself.  This  coexistence  allows  greater  versatility  in  data  sharing. 
The  description  resides  in  a  file  called  "SBSS^SCHEMAS"  that  also  contains  the  data 
dictionary.  The  database  description  identifies  the  location  of  each  data  element  by  coding 
what  record  it  is  stored  within.  Each  record  is  identified  by  a  unique  three-character 
code  which  also  is  the  first  three  characters  of  the  data  element  label.  For  instance,  the 
element  "National  Stock  Number"  is  code  "AQNOOl ,"  meaning  it  is  the  first  element  in 
the  "AQN"  record  (AFM  67-1,  Vol  II,  Part  4,  Chapter  5,  Section  A,  1991;  "Element  and 
Property  Definition  Information  List,"  1992). 

The  CAMS  database  is  managed  through  a  network  database  structure.  Similar  to 
a  hierarchical  structure,  the  network  structure  also  requires  passing  through  several 
layers  to  arrive  at  the  data  element.  Access  to  the  data  element  is  through  a  database  key. 
The  key  is  composed  of  the  area  name,  page  number,  and  record  number  that  the  data 
element  resides  in  (AFM  66-279,  Vol  I,  1990). 

The  description  of  the  CAMS  database  is  included  in  files  integral  to  the  database, 
again,  making  data  sharing  easier.  The  overall  description  is  contained  in  a  file  called 
"SCH/DOC-5R1"  with  paths  between  levels  described  within  files  called  "QLP/DOC- 
5R1"  for  single-level  navigation  and  "CV/DCX^-5R1"  for  selected  multi-level  navigation 
(AFM  66-279,  Vol  XIX,  1992). 

The  OLVIMS  was  built  without  using  a  database  management  system.  Absence  of  a 
database  management  system  makes  data  sharing  very  difficult  for  reasons  explained  in 
the  applications  section.  In  order  to  allow  ad  hoc  inquiries  of  the  system,  a  conversion 
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application  was  designed  to  translate  the  OLVIMS  files  into  CONDOR  III  formatted  database 
management  files.  Using  Condor  III  allows  inquiries  other  than  standard  reports  to  be 
made  utilizing  the  CONDOR  III  database  management  system  (Farrell,  1992;  AFM  77- 
320,  Vol  1,  1992) 

Data.  Fifty  data  elements  from  the  three  logistics  information  systems  were 
compared.  Elements  were  chosen  as  those  most  likely  to  either  be  shared  aiDong  the 
three  systems  or  required  for  management  reports  and  review.  These  elements  were 
confirmed  by  the  thesis  advisors.  The  list  of  data  elements,  along  with  the  systems  in 
which  they  reside  and  their  structure,  is  contained  in  Table  4. 


TABLE  4 

Data  Elements  Within  Logistics  information  Systems 


Data  Element 

SBSS 

CAMS 

OLVIMS 

1 

ACTION  DATE 

5  N 

2 

ACTION  TIME 

4X 

Encffls^i 

3 

APPOINTMENT  DATE 

COST 

lOX 

5 

DATE 

6  N  (YYMMDD) 

6 

DATE 

5  N 

m 

DATE 

4  X 

8 

DATE  OPENED 

9 

DOCUMENT  NUMBER 

8X 

10 

DOCUMENT  NUMBER 

14  X 

14  X 

14  X 

1 1 

DOCUMENT  NUMBER 

16  X 

12 

DOLLAR  VALUE 

EBRSlHii 

13 

ELEMENT  OF  EXPENSE 
INVESTMENT  CODE 

3X 

3X 

14 

ELEMENT  OF  EXPENSE 
INVESTMENT  CODE 

5  X 

TABLE  4,  Continued 


1 5  EMPLOYEE  NUMBER 


16  EQUIP  ID/SERIAL  NUMBER 


1  7  EXTENDED  COST 


1  8  EXTENDED  COST 


1  9  EXTENDED  COST,  SIGNED 


20  EXTENDED  PRICE 


Data  Element 


2 1  NATIONAL  STOCK  NUMBER 


22  NSN/PN/QRL  NR 


23  NOMENCLATURE 


24  ORGANIZATION  CODE 


25  ORGANIZATION  CODE 


26  ORGANIZATION 

IDENTIFICATION  CODE 


2  7  ORGANIZATION/SHOP  CODE 


ANTITY 


ANTfTY 


30  lOUANTfTY 


UANTfTY 


m 

m 

r 

E 

m 

m 

m 

m 

m 

m 

m 


ANTITY 


ANTfTY 


ANTfTY 


ANTfTY 


ANTfTY 


ANTfTY 


ANTfTY 


39  QUANTfTY  ORDERED/ 
DUE  IN 


40  RESPONSIBILITY/COST 
CENTER  CODE 


41  STOCK  NUMBER 


42  TIME  OPENED 


TABLE  4,  Continued 


Data  Element 

SBSS 

CAMS 

OLVIMS 

43 

TOTAL  COST 

44 

TOTAL  COST 

7  N 

45 

UNIT  OF  ISSUE 

2  X 

2  X 

46 

UNIT-ID 

1  A 

2  X 

47 

URGENCY  JUSTIFICATION 
CODE 

2  X 

2  X 

48 

USER  IDENTIFICATION 

6X 

49 

VEHICLE  REGISTRATION 

NUMBER 

8X 

6X 

KEY:  The  initial  numeral  indicates  the  number  of  characters  available  to  the  data 
element.  The  second  group  of  characters  indicates  the  type  of  characters  allowed  in  the 
data  element.  The  group  in  parenthesis  indicates  a  specific  format  that  is  required  for 
that  data  element. 


r— 

Data  Type 

Format 

m 

Any  Character 

m 

Year 

A 

Alphabetic  Character 

M 

Month 

N 

Numeric  Character 

D 

Day 

SN 

Signed  Numeric  (+  or  -) 

H 

Hour 

M 

Minute 

9 

Decimal  Place,  1  for  each 

(AFM  66-279,  Vol  XXVII,  1992;  AFM  77-320,  Vol  1,  1992;  "Element  and  Property 
Definition  Information  List,"  1992) 


Data  Dictionary.  The  SBSS  was  the  only  system  studied  that  has  a  computerized 
data  dictionary.  It  lists  the  data  code  which  identifies  the  record  the  data  resides  in,  the 
name  of  the  data  element,  and  the  input,  interrogation,  and  output  formats  of  the  data.  It 
does  have  shortcomings,  however.  The  data  dictionary  does  not  have  a  narrative 
description  of  the  data  elements  even  though  several  have  identical  or  similar  names  but 
different  structures.  For  instance.  Table  5,  data  elements  5  through  7  are  all  DATE,  one 
with  six  numerals,  one  with  five  numerals,  and  the  last  with  four  characters  of  any 
kind.  There  are  ten  QUANTITYs  with  as  many  different  structures.  The  lack  of 


34 


exhaustive  definitions  will  cause  problerns  in  identifying  appropriate  data  elen^nts  and 
could  lead  to  incorrect  or  nonsensical  results. 

The  CAMS  contains  20  subsystems  within  its  overall  umbrella.  Each  of  the  20 
subsystems  is  accompanied  by  its  own  manual  which  contains  the  data  dictionary  for  that 
subsystem.  Data  elements  compared  in  this  study  are  from  the  Maintenance-Supply 
Interface  Subsystem  which  is  described  in  AFM  66-279,  Vol  XXVII,  1  March  1992. 

The  CAMS  data  dictionary  provides  sufficient  detail  to  identify  the  furK:tion  as 
well  as  the  structure  of  each  data  element.  The  data  dictionary  is  arranged  input  and 
output  format  screens  with  data  descriptions  arranged  in  the  order  in  which  they  appear 
on  the  screen.  There  is  no  comprehensive  dictionary  that  lists  data  elements  in 
alphabetical  order  nor  is  there  any  indication  of  how  or  where  the  data  is  stored.  This 
arrangement  of  data  elements  makes  identifying  eligible  elements  for  data  sharing  very 
difficult.  It  also  could  lead  to  errors  caused  by  falsely  identifying  data.  Data  stored  in 
one  element  could  easily  be  mistaken  for  multiple  elements  or  different  data  elements 
for  references  of  a  single  element.  This  is  the  result  of  the  confusion  caused  by  element 
names  which  are  listed  in  multiple  screens  but  no  storage  location  is  given. 

OLVIMS  data  definitions  listed  in  AFM  77-320  Vol  1,  1  May  1992,  are  the  most 
comprehensive  of  the  three  systems  studied.  However,  like  the  CAMS,  the  data  elements 
are  grouped  by  screens  and  listed  in  the  order  of  their  appearance.  Also,  the  lengths  of 
the  data  elements  are  not  explicitly  stated.  L^gths  were  determined  in  this  study  by 
either  reviewing  the  format  within  the  definition  of  the  element  or  by  counting  the 
spaces  shown  on  the  screen  rendition  in  the  manual,  a  very  risky  arrangement.  Errors 
in  data  element  length  could  make  data  sharing  difficult.  For  instance,  in  Table  5,  data 
element  22,  OLVIMS  allows  12  characters,  while  S6SS  allows  18.  SBSS  sharing 
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OLVIMS’  NATIONAL  STOCK  NUMBER  would  not  be  a  problem  because  SBSS  NATIONAL 
STOCK  NUMBER  is  larger  than  OLVIMS  NATIONAL  STOCK  NUMBER.  OLVIMS  sharing  SBSS 
NATIONAL  STOCK  NUMBER  would  require  some  n^ethod  of  shortening  the  data  element  in 
order  that  it  would  fit  into  OLVIMS’  allocated  space. 

Data  Element.  Data  is  most  easily  shared  when  the  format  for  the  data  element  is 
identical.  For  instance,  Table  5,  data  element  15,  EMPLOYEE  NUMBER,  is  identically 
formatted  for  CAMS  and  OLVIMS.  An  identical  format  allows  an  employee  number  to  be 
used  by  either  system  without  adverse  effects.  Identical  data  elements  occur  in  Table  5, 
Elements  1,10,  33,  39,  40,  and  46. 

For  data  elements  that  are  not  identically  formatted,  the  data  must  be  converted  to 
a  common  format  before  sharing.  This  action  can  become  quite  involved  and  may  require 
user  intervention.  For  instance.  Data  Element  4,  COST,  when  sharing  from  SBSS  to 
OLVIMS,  requires  that  multiple  manual  transactions  be  made  to  account  for  items  that 
cost  $10,000.00  or  more.  Other,  less  critical  data  are  truncated  automatically,  such  as 
data  element  23,  NOMENCLATURE,  or  zeros  in  specific  places  are  removed,  such  as  data 
element  50,  VEHICLE  REGISTRATION  NUMBER,  so  that  the  data  will  fit  into  the  data 
element  (AFM  77-320,  Vol  I). 

Summary 

Chapter  IV  described  the  the  four  factors  considered  significant  to  data  sharing 
within  Chapter  III:  input  and  output  devices,  applications,  database  management  system, 
and  data,  in  relation  to  the  three  logistics  information  systems.  Chapter  V  will  provide  a 
summation  of  Chapters  I  through  III,  provide  conclusions  drawn  from  the  results 
reported  in  Chapter  IV,  and  list  recommendations  to  enhance  data  sharing  between  the 
logistics  information  systems.  Finally,  topics  for  further  study  will  be  considered. 
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V.  Summary.  Conclusions,  and  Recommendations 


Oroanization  of  the  Present  Chapter— Overview 

This  chapter  provides  a  sumirratiorr  of  Chapters  I  through  III,  draws  corrclusions 
from  the  results  reported  in  Chapter  IV,  and  list  recommendations  to  enhance  data 
sharing  between  the  logistics  information  systems.  Finally,  topics  for  further  study 
will  be  considered. 

Summary 

The  Air  Force  has  changed.  With  this  change  has  come  a  shift  in  management 
responsibilities  within  the  logistics  community.  Formerly  diverse  functions  have  come 
under  the  purview  of  a  single  manager— the  Logistics  Group  Commander.  This  single 
manager  has  inherited  information  systems  that  may  or  may  not  be  able  to  provide 
consolidated  information  in  order  to  make  informed  and  accurate  decisions.  The  purpose 
of  this  thesis  was  to  describe  the  current  and  potential  ability  for  three  logistics 
information  management  systems  to  share  data. 

A  literature  review  conducted  within  the  scope  of  this  thesis  has  discovered  two 
theories  on  how  data  sharing  might  be  possible.  The  first  was  to  design  or  redesign  all 
information  systems  to  share  data.  The  second  was  to  design  an  open  system  interface 
that  would  use  artificial  intelligence  to  translate  data  and  inquiries  between  database 
management  systems.  Ail  of  the  authors  admitted  that  no  fully  shared  data  ^stene  have 
been  implemented  as  of  this  writing. 

This  thesis  used  the  case  study  methodology  to  produce  its  results.  Data  collection 
was  through  documentation  research  with  secondary  emphasis  placed  on  personal 
interviews  using  open  ended  questions.  The  components  of  the  logistics  information 
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systems  that  were  evaluated  for  inclusion  in  the  study  were  input,  output,  applications, 
database  management  system,  operating  system,  programming  language,  computer 
hardware,  and  data.  The  four  areas  that  could  have  impacted  data  sharing  and  were 
included  in  a  more  thorough  investigation  were  the  input  and  output  (treated  as  a  single 
component),  applications,  database  management  system,  and  data. 

Conclusions 

Input  and  Output.  All  systems  had  adequate  input  and  output  methods  to  share  data 
with  other  systems.  The  input  and  output  for  the  OLVIMS,  however,  was  inadequate  for 
increasing  the  frequency  of  sharing  data  above  that  which  was  used  at  the  time  of  this 
study.  Limiting  input  to  the  terminal's  keyboard  or  to  a  magnetic  disk  may  require  an 
inordinate  amount  of  time  and  effort  to  be  expended  by  an  operator  in  relationship  to  the 
amount  and  significance  of  the  data  that  is  entered  into  the  system.  S6SS  and  CAMS  have 
the  greatest  potential  for  sharing  data  because  both  systems  share  hardware.  CAMS  and 
OLVIMS  have  the  least  potential  for  sharing  data  because  there  are  no  high-speed 
common  input  and  output  methods  between  the  two. 

Applications.  The  SBSS  and  CAMS  applications  were  neither  a  hindrance  nor  a 
help  to  sharing  data  between  systems.  Because  the  applications  acted  as  front  ends  to 
database  management  systems,  the  applications  did  not  directly  affect  the  data.  Within 
OLVIMS  the  applications  did  directly  affect  the  data.  The  structure  of  the  data  was 
contained  within  the  application  itself;  therefore,  any  attempt  to  share  the  data  would 
require  intimate  knowledge  of  the  application  In  order  to  share  the  data  with  another 
system.  SBSS  and  CAMS  have  the  greatest  potential  for  sharing  data  because  of  the 
absence  of  application  specific  data.  OLVIMS  has  the  least  potential  for  sharing  data 
because  of  its  application  specific  data  requirement. 
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Database  Management  System.  The  use  of  a  database  management  ^stem  within 
the  S6SS  and  the  CAMS  significantly  enhanced  the  ability  to  share  data  contained  within 
the  systems.  The  data  structure  and  relationships  were  readily  available  without  having 
intimate  knowledge  of  the  application.  Inquiries,  rrxxlifications,  additions,  and  deletions 
could  be  made  utilizing  the  utilities  within  the  database  management  system.  SBSS  and 
CAMS  have  the  greatest  potential  for  sharing  data  because  of  their  use  of  standardized 
database  management  systems.  OLVIMS  has  the  least  potential  for  sharing  data  because  of 
its  lack  of  a  standardized  database  management  system. 

Data.  The  largest  obstacle  for  sharing  data  in  all  three  systems  was  the  data 
itself.  All  three  systerrrs  had  shortfalls  in  the  documentation  describing  the  data 
elements.  The  SBSS  data  dictionary  was  the  easiest  to  use,  but  did  not  contain  data 
descriptions  to  differentiate  elements  with  identical  or  similar  names.  The  OLVIMS  data 
dictionary  had  the  best  descriptions  of  the  data,  but  was  ungainly  to  use  and  did  not 
definitively  identify  the  lengths  of  the  elements. 

The  shortfalls  within  each  data  dictionary  made  identification  of  all  identical  data 
elements  impossible.  Even  though  the  SBSS  and  CAMS  and  the  SBSS  and  OLVIMS  regu¬ 
larly  interact,  the  documentation  was  not  comprehensive  enough  to  identify  which  data 
elements  were  being  used  between  the  ^rstems.  The  inadequacies  of  the  data  dictionaries 
would  preclude  any  universal  data  sharing  between  the  three  systems  studied  and  any 
other  systems. 

Recommendations 

Any  information  management  system  can  be  improved,  but  the  purpose  of  this 
section  is  not  to  find  fault  but  to  recommend  areas  that  need  attention  in  order  to  facili¬ 
tate  data  sharing.  Some  data  sharing  has  occurred,  but  the  potential  exists  that  much 
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more  could  occur  with  some  modifications  to  the  existing  logistics  managen^ent  systems. 
The  recommendations  are  listed  in  decreasing  order  of  significance. 

Emphasis  should  be  placed  on  completing  the  data  dictionaries  within  each  logis¬ 
tics  information  system.  Only  then  can  any  real  progress  be  made  on  sharing  data 
between  systems.  Without  a  comprehensive,  logically  ordered  data  dictionary  available 
for  systems  developers,  any  attempt  at  sharing  data  among  new  or  existing  systems 
would  be  very  difficult  or  futile. 

The  input  and  output  capability  of  OLVIMS  should  be  enhanced.  The  limitation  of 
methods  to  communicate  with  other  systems  (xecludes  data  sharing. 

OLVIMS  should  be  redesigned  around  a  database  management  system.  With  an 
application  independent  database,  data  sharing  as  well  as  ad  hoc  inquiries  would  be 
significantly  simplified. 

Further  Study 

This  thesis  is  only  a  scratch  on  the  surface  of  a  very  large  mountain.  The  1 9 
other  modules  of  CAMS  as  well  as  all  the  other  logistics  management  systems  within  the 
Air  Force  deserve  similar  analysis.  Also,  when  adequate  data  dictionaries  becorrre 
available  for  the  three  logistics  support  systems  studied  within  this  thesis,  data 
elements  could  be  scrutinized  to  determine  if  the  systems  could  be  streamlined  while 
data  elements  can  be  eliminated,  consolidated,  or  otherwise  modified,  further 
simplifying  already  complex  logistics  information  systems. 


Appendix:  Acronyms 


CAMS:  Consolidated  Aircraft  Management  System 

COBOL:  common  Business  Oriented  Language 

CODASYL  Committee  On  DAta  SYstems  Languages 

DBMS:  Database  Management  System 

DDN:  Defense  Data  Network 

ICI:  Interactive  Communication  Interface 

OLVIMS:  On-Line  Vehicle  Interactive  Management  System 

SBSS:  Standard  Base  Supply  System 

TCP/IP:  Transmission  Control  Procedure/Intemet  Protocol 

VIMS:  Vehicle  Integrated  Management  System 
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